Conventional CRC operation involves processing a data stream against a known CRC polynomial that yields a result that is nearly unique to that data stream. Modifications of bits in the data stream cause different CRC results. Consequently, if data is corrupted in delivery of the stream, the calculated CRC results will not match the expected CRC results. The width and values in the polynomial determine the strength (uniqueness) of the CRC. A next-state decoder (NSD) implements the calculation of the CRC polynomial against the incoming data. The CRC is widely applicable in many situations, for example, in endeavors that transmit, receive, store, retrieve, transfer, or otherwise communicate electronically represented digital information.
According to conventional CRC operation, and as shown in FIG. 1, a syndrome 11 contained in a feedback register (FB REG) 12 is fed back to the syndrome input 10 of the NSD 14. The NSD 14 also receives the current piece of incoming data 13. The resulting output 15 of the NSD 14 is registered into the feedback register 12, and thus becomes the next syndrome at 11 for the NSD 14 to use with the next piece of incoming data at 13. The initial state of the feedback register 12 (i.e., the initial syndrome value 11) is set to an appropriate value for the CRC polynomial that has been selected for use. A checksum generator 16 performs a predetermined operation on the final syndrome value 11 contained in the feedback register 12 after all of the incoming data 13 has been processed. The checksum generator 16 produces a CRC checksum value 17. The checksum value determined by the checksum generator 16 could be associated with (e.g., concatenated with, appended to, etc.) the data 13 for transmission, transfer, storage, etc., together with the data. An example would be a transmit packet having a checksum field associated with its data (payload) portion. The checksum value determined by the checksum generator 16 could be compared to a further checksum value that has been received, retrieved, etc., together with the data 13. An example would be a received packet whose checksum field contains the further checksum value and whose data (payload) portion contains the data 13. Comparison of the further checksum value to the checksum value determined by the checksum generator 16 provides a basis for evaluating the validity of the received data 13.
In some data transmission/transfer/storage applications, the data includes a first portion that is not known before it arrives for processing, and a second portion that is to be added to the first portion. The second portion is already known before the first portion arrives. One example of a known second portion that is added to an unknown first portion can be seen on the transmit side of a conventional PCI Express application. The Transaction Layer Packet (TLP) processing in the Data Link Layer (DLL) module of PCI Express concatenates to an unknown data portion (i.e., the data payload of a PCI Express packet) an associated 16-bit data portion (including a 12-bit TLP Sequence Number) that is already known before the unknown data portion arrives. If the both the unknown and known data portions are to be covered by the checksum at 17 in FIG. 1, then the checksum will cover a larger set of data than if only the unknown data portion were covered by the checksum. As the set of data covered by the checksum increases in size, the amount of time required for the associated CRC processing correspondingly increases.
It is therefore desirable to provide for CRC processing that permits the addition of already-known data to incoming unknown data, while avoiding a corresponding increase in CRC processing time.